Service automation systems require a large number of applications compliant with the Application Packaging Standard (APS). The Application Packaging Standard (APS) is a standard that defines a technology for integrating application software with hosting platforms. Integration of an application with such hosting platforms is implemented by creating an APS package for the application, and the application is called an APS application in this case. Development on an APS platform allows for universal use of an application on different hosting platforms. Such applications are also deployed in various regions of the world in native languages and/or dialects. In order for such applications to be used, their Graphical User Interfaces (GUI) are sometimes deployed using the local language. For example, where a GUI might have a text element that is in English when presented to a user in the United States (U.S.), the same GUI element may have the same text translated into Russian, when presented to a user in Russia. Using a local language (as opposed to English only) for GUI elements allows for a customized and improved user experience.
Internationalization (i18n) is the process of developing an application such that the strings and other locale-specific bits (such as date or currency formats) can be abstracted out of the application so they can be localized for languages and cultures easily. Localization (l10n), is the process of adapting applications and text to enable their usability in a particular cultural or linguistic market by providing translations and localized formats for the abstracted bits. For example, making a U.S. application accessible to Australian or British users may require a little more than a few spelling corrections. But to make a U.S. application usable by Japanese users, or to make a Korean application usable by German users, will require the software to operate not only in different languages, but also to use different input techniques and presentation conventions.
Developing a GUI (and the GUI elements therein) for each language and for each application is not a viable proposition. The time, effort and money required to develop so-called “language native” GUIs can be burdensome when trying to deploy an application in multiple regions of the world.
To reduce the burden, software and development platforms, such as for example, the APS platform, allow for GUI elements to be localized and translated. This allows for a GUI, when rendered, to be in a language that is native to the region (or the user). However, traditional translations and conversions of the GUI interface elements do not present consistently. This can be because the character set that comprises the alphabet of one language is different from another language; the change in spatial characteristics renders the text in the translated language larger (or smaller); or there is meaning “lost in translation.”
Furthermore, when a GUI is developed or improved, the amount of data rendered on the screen to the end user may increase, including any text messages that the user sees as part of the GUI. In particular, the number of lines, marks of the interface elements, and screen forms tend to increase. According to the APS standard, all application interface elements have to be localized and internationalized. However, the interface lines and elements are not always properly formatted after they are included into the application code. As a result, the end user can observe glitches caused by a partial localization and translation of messages inside the application.
For example, referring now to FIG. 1, there is shown an embodiment of a conventional method for translation of un-localized lines of an APS compatible application, generally at 100. The conventional method includes step 102 of collecting the source code; step 104 of importing of localization through msgmake posts; step 106 of creating portable objects (.po) message files; step 108 of transferring the msgmake posts to a technical writer who drafts translations for the un-localized lines; step 110 of adding the translation; step 112 of building the APS package by exporting the localized message in JavaScript Object Notation (JSON); which results at 114 with the APS package with internationalization files.
In the conventional method 100, not all lines can be presented and localized into the interface correctly. The reasons for this can include, but are not limited to, incorrect format of the localities, a processor error, an incorrect key, lack of available translations, or typos or missing files relating to an additional locality, to name a few non-limiting examples. This results in an incomplete implementation of required scenarios and in high costs associated with checks and verifications.
Ideally, the above problems can be prevented in the application development phase. Furthermore, automated and semi-automated checks of correctness of translation of GUI elements are desired. This will help improve the checks and reduce costs associated with manual verification. Lastly, a method for timely detection of localization errors within the application lifecycle management is desired.
Therefore, there is a need for a method for automated detection, correction, and translation of un-localized lines.